Utilisateur:Smail el/Brouillon

Une page de Wikipédia, l'encyclopédie libre.

La vulnérabilité des services d'authentification web correspond aux faiblesse des protocoles authentification du web.

Différentes vulnérabilités ont été exploitées ces dernières années contre les services d'authentification, notamment, HTTP et HTTPS qui ont fait l'objet de diverses attaques. Ces attaques sont de plus en plus sophistiquées et touche désormais les navigateurs. Face à cela, les développeurs ont décidé d'augmenter la sécurité de leur logiciel en proposant de nouvelles fonctionnalités, par exemple, un système de gestion de mot de passes.

Vulnérabilités des techniques d'authentification[modifier | modifier le code]

Introduction aux protocoles d'authentifications[modifier | modifier le code]

Article principal : authentification.

Les usagers d’internet sont confrontés à un nombre croissant d’applications web nécessitant de s’authentifier. Cette authentification permet de s’assurer que l’utilisateur est bien la personne qu'il prétend être mais aussi de lui fournir des informations personnalisées en fonction de son profil et des données personnelles qu’il transmet. Elle est donc sujette à de nombreuses attaques de la part de personnes malveillantes qui souhaitent en exploiter toutes ses vulnérabilités. L’exploitation de ces failles peut être utilisée pour compromettre les services d’authentification web, même les plus forts et les plus connus, que se soit par mots de passes, cookies d'authentification, ou avec l'utilisation de SSL.

Authentification HTTP[modifier | modifier le code]

L'authentification HTTP permet de s'identifier auprès d'un serveur HTTP à l’aide d’un nom d’utilisateur et d’un mot de passe. Il existe deux méthodes

HTTP Basic[modifier | modifier le code]

Cette méthode est la plus simple mais également la moins sécurisée. Elle utilise une combinaison d'un nom d'utilisateur et mot de passe pour authentifier l'utilisateur. Le nom d'utilisateur et le mot de passe sont concaténés avec deux points et le tout est encodé en base 64. Il est donc très facile de décoder les données et d'obtenir les informations d'identification. Cette méthode est donc très vulnérable aux attaques par écoute. Il est possible de diminuer les risques par l'utilisation du protocole SSL, qui va envoyer les données sous forme chiffrée. Toutefois, elle sera toujours vulnérable à de nombreuses attaques côté client, y compris l'attaque de l'homme du milieu et également vulnérable aux attaques par brute force.    

HTTP Digest[modifier | modifier le code]

L'authentification Digest a été conçu comme une amélioration de la l'authentification HTTP de base. L'une des principales améliorations est que les données ne sont pas transmises en clair mais sont transmises à l'aide d'un message digeste chiffré. Si cette méthode est moins vulnérable aux attaques par écoutes, elle le reste encore aux attaques par rejeu. En effet, si un attaquant est en mesure de rejouer le message digeste chiffré alors le serveur lui donnera l’accès.

Toutefois, il arrive que le nonce fournit par le serveur contienne un timestamps. Ce qui permet au serveur d'en vérifier la valeur lors de l'authentification, si la valeur du nonce est dépassé, alors la demande du client est rejeté.

Authentification par cookies[modifier | modifier le code]

Les cookies sont le moyen principal pour les applications webs d’authentifier les requêtes http et de maintenir la connexion avec le client. Ils relèvent donc d’un grand intérêt pour les pirates. Un protocole de cookie sécurisé devrait donc être en mesure de proposer les quatre services suivant [1]: l'authentification, la confidentialité, l’intégrité et la non duplication. Toutefois, en pratique, il en est tout autrement.

Vol de cookies[modifier | modifier le code]

Le détournement de cookie est un procédé par lequel le pirate va obtenir un accès non autorisé à des informations confidentielles. Pour cela, il va voler les cookies qui contiennent les informations nécessaires pour authentifier un utilisateur à un serveur web distant. Il suffit juste que la valeur du cookie existe dans la requête pour être authentifié auprès du serveur. Dès lors, n’importe quelle personne possédant la valeur du cookie est en mesure de s’authentifier avec l’identité de l’utilisateur . Ce détournement peut être effectuée par le pirate en utilisant un ordinateur entre le noeud et le serveur ou en récupérant directement les cookies stockés sur l'ordinateur de l'utilisateur. Par défaut, la valeur du cookie est envoyé en clair, chaque parti ayant accès au réseau peut renifler la valeur de l’abus à l’avenir. Alors que SSL/TLS protège contre cette menace, de nombreux sites ne protégeant que la page de connexion avec SSL / TLS puis revienne à du http laissant la valeur du cookie exposé [2]. Toutefois, même avec l’existence d’une connexion SSL/TLS, le cookie est lisible par défaut avec JavaScript via la propriété document.cookie. De ce fait, l’utilisation d’un Cross-site Scripting (XSS) permet quand même au pirate d’obtenir la valeur du cookie. Pour contrer cette menace, les éditeurs de navigateurs ont introduit le HTTPonly-flag qui permet de cacher la valeur du cookie depuis javascript.

Fixation de session[modifier | modifier le code]

L’attaque par fixation de session est une attaque proche du vol de session. Cette attaque permet à une personne mal intentionnée de déterminer l'identifiant de session (SID ou "session ID") d'une autre personne. Si vous connaissez le SID d’un utilisateur, alors vous pouvez l’utiliser et récupérer sa session comme si c’était la vôtre. Cette attaque repose sur le fait, que lorsqu’un utilisateur s’authentifie, un nouveau SID ne lui est pas attribué, ce qui rend possible l’utilisation de son SID.

Avec cette attaque, l’attaquant fixe le  SID de l’utilisateur, avant même que celui ci n’ouvre une session sur le serveur cible. Cette méthode évite ainsi à l’attaquant de devoir récupérer par la suite le SID de l’utilisateur. Pour se faire [3], l’attaquant ouvre une session sur le serveur et obtient un SID valide. Puis il transmet ce dernier à sa victime, à l’aide d’un lien, par exemple au travers d’un email. Le victime clique sur le lien et se connecte au serveur. Une fois la connexion établi, l’attaquant peut envoyer de nouvelles requêtes aux serveurs et comme il possède le même SID, il a accès aux données. La session a été détournée.

principe d'une attaque par fixation de session
injections de requêtes illégitimes par rebond[modifier | modifier le code]

L’objet de cette attaque est de forcer des utilisateurs à exécuter une ou plusieurs requêtes non désirées sur un site donné. L’utilisateur devient donc complice d’un attaque sans même en avoir conscience. Cette dernière étant actionnée par l'utilisateur, un grand nombre de systèmes d'authentification sont contournés. Pour cette attaque, l’attaquant falsifie une requête HTTP qui pointe sur une action précise interne au site (souvent par le biais d’une URL, ou d’un formulaire). Puis se charge de la transmette à la victime afin que celle ci l'exécute sans en avoir conscience. L'intérêt de cette attaque et de pouvoir obtenir les droits de la victime pour réaliser une action dont il ne possède pas l’autorisation.

Attaque par hameçonnage[modifier | modifier le code]

Un autre menace répandue est connue par le terme hameçonnage (ou phishing en anglais). Elle consiste à employer diverses techniques pour récolter les information d’un utilisateur. Cette collecte d'informations illégale peut être réalisé par plusieurs méthodes mais la plus répandu et le déploiement d’un faux site en trompant l'utilisateur sur sa légitimité . Pour être réalisée, l’attaquant imite un site et son nom de domaine. Puis il transmet ce site, quasi semblable au site légitime, à la victime. L'utilisateur tente donc de s'identifier  au sein du site contrefait, tout en pensant être sur le site légitime. Et comme avec le protocole http, les mots de passes sont transmit en clair, l’attaquant peux les récupérer. La capacité des utilisateurs à identifier de manière fiable la légitimité d'un site Web est donc essentiel[4].

Ces techniques d’attaques sont devenues de plus en plus sophistiquée. Certains hameçonneurs[5] vont jusqu’à faire suivre les données jusqu'au site authentique afin de voler ou détourner la session de la victime. Prenons l’exemple d’une victime qui transmet les données de son compte bancaire pour un transfert d’argent, l’attaquant peut modifier la requête pour rediriger le transfert sur son propre compte. Une façon de se prémunir est d’utiliser l’authentification mutuelle, également appelée l’authentification à double sens. Avec ce procédé, les deux entités doivent s’identifier mutuellement avant de pouvoir communiquer: le client authentifie le serveur et vice et versa. L’utilisateur s’assure donc de bien communiquer avec le serveur légitime et réciproquement le serveur s’assure que l’utilisateur est là dans un but légitime.

Une variante de l'hameçonnage est le dévoiement (ou pharming[6] en anglais). Ce type d’attaques vise à pratiquer l' hameçonnage par la redirection de l'utilisateur, grâce au DNS, sur un serveur contrôlé par l’attaquant. Pour mener cette attaque, l’attaquant peut par exemple[7] fournir un document web contenant un code malveillant à sa victime, puis exploiter la vulnérabilité du navigateur à gérer le DNS et forcer le navigateur de la victime à se connecter au serveur. Une fois l’utilisateur authentifié auprès du serveur, l’attaquant utilise le code malveillant pour détourner la session de la victime authentifiée.

Authentification HTTPS[modifier | modifier le code]

TLS «  Transport Layer Security » aussi connu sous le nom, précédent, de Secure Sockets Layer (SSL) est un protocole qui a pour objectif de fournir la confidentialité et l'intégrité des données entre deux applications en communication. Son utilisation conjointe avec le protocole HTTP permet de se protéger contre certaines attaques en chiffrant les communications et les authentifications clients/serveurs. HTTPS permet donc de transférer des données par le port 443 en utilisant un chiffrement asymétrique. Toutefois même si ce protocole est plus sécurisé, il peut également être compromis de différentes façons. Par exemple, Burkhoder[8] a proposé une attaque qui consiste  à renifler les données HTTPS en utilisant un faux certificat.

Man-In-The-Browser
L'attaque proposée par Marlingspike contre SSL (Man-In-The-Middle)

On peut également mentionner l' attaque qui consiste à ce qu’une personne malveillante se mette au milieu de la conversation et se fasse passer pour le serveur. Ou l' attaque qui a été proposé,en 2009, par Marlingspike et qui est difficilement repérable par la victime car elle peut être menée sans avertissement de la part du navigateur. Plus précisément, cette attaque consiste à détourner le trafic HTTPS sur un réseau et redirige vers du HTTP normal,puis envoie ce trafic HTTP au client ce qui permet d'espionner des informations confidentielles. Les navigateurs web (tels que Chrome, IE, Firefox, Opera, Safari) donnent des messages d’avertissement sérieux face à un faux certificat SSL, pour éviter ces messages, Marlingspike a proposé une nouvelle technique de décapage SSL qui consiste à intercepter la communication, puis détourner le trafic HTTPS sur un réseau et le rediriger vers le navigateur client, les communications dans ce cas peuvent donc être espionnées puisqu’il n’y a plus de chiffrement et dans ce cas l’attaque peut se faire sans l’avertissement de navigateur[9].


Vulnérabilités des navigateurs[modifier | modifier le code]

Gestionnaire de mot de passes [10][modifier | modifier le code]

La concurrence dans le marché des navigateurs motive les développeurs à en faire plus qu’un simple outil pour la visualisation des pages web. La norme ISO 9126[11], définit la qualité des fonctionnalités proposés par ces navigateurs. L’une d’elle consiste en la mise en place d’un système de gestion de mot de passes.

Ce besoin authentification provient du fait que de nombreuses applications webs implémentent des sessions sécurisées qui demandent à l’utilisateur de s’authentifier à l’aide d’un nom d’utilisateur et d’un mot de passe. Ces méthodes obligent donc l’utilisateur à connaître ses multiples identifiants suivant chaque site. Face à cette problématique, les développeurs de navigateurs ont donc mit en place ce système de gestion de mots de passes, simplifiant l’authentification de l’utilisateur. Ce système demande simplement à ce que l'utilisateur se souvienne d'un mot de passe maître qui sera utilisé pour déchiffrer les autres qui se trouve dans la base de données du gestionnaire de mot de passe.

L'utilisation d'un gestionnaire de mot de passe à un autre avantage. L’adresse URL, ou au moins le nom de domaine, est stockée à côté du mot de passe correspondant. Elle permet au navigateur de remplir automatiquement le formulaire de connexion. Si l'utilisateur est dirigé vers un site web malveillant qui est conçu pour ressembler à l identique au site légitime qu'il attend alors le gestionnaire de mot de passes ne pourra pas auto compléter les champs du formulaire et connecter l’utilisateur. Ainsi, les utilisateurs qui utilisent un gestionnaire de mot de passe sont moins sensibles aux typosquattages [12] et aux attaques par hameçonnages.

Firefox[modifier | modifier le code]

Mozilla Firefox stocke ses données de connexion dans deux fichiers différents. Le premier fichier key3.db stocke le mot de passe principal pour accéder à la base de données, le second signons.sqlite stocke les mots de passes et les adresses de sites dans une base SQLite. Les identifiants sont chiffrés avec le mot de passe maître du fichier key3.db et encodé en Base64. Si l'utilisateur ne fournit pas de mot de passe maître alors Firefox utilise une valeur pas défaut pour chiffrer les données. . Quant aux adresses URLs, elles sont toujours stockées en clair avec ou sans mot de passe maître.

Si un attaquant souhaite déchiffrer les données de signons.sqlite, il doit d'abord obtenir le mot de passe principal stocké dans key3.db. Pour cela différentes méthodes sont possibles: les attaques par brute force, soit en générant tous les mots de passe possibles à partir d'un vocabulaire donné, soit en utilisant un dictionnaire.

La sureté des différents mots de passe, repose donc sur la robustesse[13]du mot de passe principal.

Firefox stocke aussi d’autres données non chiffrées, comme le nom des champs de formulaire renseignés avec le mot de passe et le nom d’utilisateur. Le problème est que si un attaquant arrive à obtenir l’accès à la base de données, il peut récolter une quantité d’informations considérables. Il peut par exemple récupérer les adresses des sites webs où la victime à des mots de passes enregistrées et monter une attaque par hameçonnage en se basant sur les informations récoltées.

Google Chrome[modifier | modifier le code]

Google Chrome stocke les noms d'utilisateur et mots de passe, ainsi que d'autres données personnels dans un fichier de base de données SQLite dans le répertoire du profil utilisateur. Seul, le mot de mot de passe est chiffré et les autres donnés sont accessibles facilement. De ce fait, n'importe quelle personne ayant accès à la base de données peut en lire le contenu et y apporter facilement des modifications. L'utilisateur ne peut donc pas se fier à la confidentialité et l'intégrité de ses données. De même, Google Chrome ne propose pas de mot de passe principal comme sous Firefox. Mais il est possible d'installer une extension qui ajoutera cette fonctionnalité et permettra d'ajouter une couche de sécurité

Il est également possible de stocker les identifiants sur les serveurs de Google pour permettre la synchronisation avec les différents appareils. Les pages de support de Chrome affirment que les mots de passe sont stockés sous forme chiffrée sur les serveurs de Google [14]

Internet Explorer[modifier | modifier le code]

Internet Explorer stocke les noms d'utilisateur et mots de passe dans le registre. Chaque enregistrement est stocké comme une entrée de registre distincte et est chiffrée en utilisant les informations de connexion du système. Internet Explorer stocke l'URL de la page en utilisant une fonction de hachage[15] SHA1. L'URL et le mot de passe de session sont ensuite utilisée comme clé avec un algorithme de chiffrement fournit pas Windows pour chiffrer le mot de passe et le nom d’utilisateur. La sécurité du gestionnaire de mot de passe sous Internet Explorer dépend donc également de la robustesse du mot de passe du compte utilisateur.

Méfiance des navigateurs [16][modifier | modifier le code]

Les attaques sur les flux de données entre un client et un serveur sont devenue plus sophistiquées, maintenant les attaques visent plutôt à contourner la protection de sécurité utilisée par les logiciels du client. MITB (Man-in-the-Brother) est un type d’attaque qui consiste à infiltrer un logiciel client tel que le navigateur d’une victime, ce qui permet de lui voler des informations sensibles ou de manipuler les transactions entre le client et le navigateur. L’attaque MITB est conçue pour manipuler les informations entre le client et le navigateur, ce type d’attaque est généralement compliquée à détecter en raison de sa nature qui consiste à attacher secrètement un code malveillant dans une extension de navigateur. L'attaquant attend ensuite que l’utilisateur visite certains sites web pour enregistrer les informations saisies et les manipules avant de les transmettre au serveur.

Attaque contre les navigateurs MITB (Man-in-the-Brother)

Références[modifier | modifier le code]

  1. ↑ Liu et al. 2005, p. 333 - 338
  2. ↑ Johns et al. 2012, p. 169-178
  3. ↑ Mitja 2002
  4. ↑ Darwish et Bataineh 2012, p. 1-6
  5. ↑ Yutaka, Hajime et Hiromitsu 2009, p. 1143-1144
  6. ↑ Stamm, Ramzan et Jakobsson 2007, p. 495–506
  7. ↑ Karlof , Wagner et Tygar 2007, p. P58-71
  8. ↑ Burkholder 2013
  9. ↑ Somnuk 2012
  10. ↑ Catalin 2011
  11. ↑ ISO 9126 1991
  12. ↑ Chen et al. Yin, p. 31-36
  13. ↑ ANSSI 2012, p. 7
  14. ↑ Google 2014, p. 1-6
  15. ↑ Gasti et B. Rasmussen 2012, p. 777
  16. ↑ Bin Mat Nor, Jalil et Manan 2012, p. 271-276

Bibliographie[modifier | modifier le code]

  • (en) Chomsiri, T., « HTTPS Hacking Protection », Advanced Information Networking and Applications Workshops, 2007, AINAW '07. 21st International Conference on, vol. 1,‎ , p. 590 - 594 (ISBN 978-0-7695-2847-2, DOI 10.1109/AINAW.2007.200)
  • (en) Puangpronpitag, S., « Simple and Lightweight HTTPS Enforcement to Protect against SSL Striping Attack », Computational Intelligence, Communication Systems and Networks (CICSyN), 2012 Fourth International Conference on, vol. 1,‎ , p. 590 - 594 (ISBN 978-1-4673-2640-7, DOI 10.1109/CICSyN.2012.50)
  • (en) Sugavanesh, B., Hari Prasath, R. et Selvakumar, S., « SHS-HTTPS Enforcer: Enforcing HTTPS and Preventing MITM Attacks », Newsletter, ACM SIGSOFT Software Engineering Notes, vol. 38, no 6,‎ , p. 1-4 (ISSN 0163-5948, DOI 10.1145/2532780.2532802)
  • (en) Durumeric, Zakir, Kasten, James, Bailey, Michael et Halderman, J. Alex, « Analysis of the HTTPS certificate ecosystem », IMC '13 Proceedings of the 2013 conference on Internet measurement conference,‎ , p. 291-304 (ISBN 978-1-4503-1953-9, DOI 10.1145/2504730.2504755)
  • (en) Arnbak, Axel, Asghari, Hadi, Van Eeten, Michel et Van Eijk, Nico, « Security Collapse in the HTTPS Market », Communications of the ACM, vol. 57, no 10,‎ , p. 47-55 (ISSN 0001-0782, DOI 10.1145/2660574)
  • (en) Puangpronpitag, S. et Sriwiboon, N., « Simple and Lightweight HTTPS Enforcement to Protect against SSL Striping Attack », Computational Intelligence, Communication Systems and Networks (CICSyN), 2012 Fourth International Conference on,‎ , p. 229 - 234 (ISBN 978-1-4673-2640-7, DOI 10.1109/CICSyN.2012.50)
  • (en) Nagarajan, V. et Huang, Dijiang., « Improving Secure Server Performance by EAMRSA SSL Handshakes », Industrial Control and Electronics Engineering (ICICEE), 2012 International Conference on,‎ , p. 1896 - 1899 (ISBN 978-1-4673-1450-3, DOI 10.1109/ICICEE.2012.503)
  • (en) Abd Aziz,N., Udzir, N.I. et Mahmod, R., « Performance analysis for extended TLS with mutual attestation for platform integrity assurance », Industrial Control and Electronics Engineering (ICICEE), 2012 International Conference on Cyber Technology in Automation, Control, and Intelligent Systems (CYBER), 2014 IEEE 4th Annual International Conference on,‎ , p. 13-18 (ISBN 978-1-4799-3668-7, DOI 10.1109/CYBER.2014.6917428)
  • (en) Qi,Fang, Tang,Zhe et Wang,Guojun, « Attacks vs. Countermeasures of SSL Protected Trust Model », Service Oriented System Engineering (SOSE), 2013 IEEE 7th International Symposium on,‎ , p. 584 - 593 (ISBN 978-1-4673-5659-6, DOI 10.1109/SOSE.2013.94)
  • (en) Xu,Le et Li, Li, « Secure Web Referral Services for Mobile Cloud Computing », Young Computer Scientists, 2008. ICYCS 2008. The 9th International Conference for,‎ , p. 1986 - 1991 (ISBN 978-0-7695-3398-8, DOI 10.1109/ICYCS.2008.433)
  • (en) Waleed,G.M. et Ahmad, R.B., « Security protection using simple object access protocol (SOAP) messages techniques », Electronic Design, 2008. ICED 2008. International Conference on,‎ , p. 1986 - 1991 (ISBN 978-1-4244-2315-6, DOI 10.1109/ICED.2008.4786714)
  • (en) Liu,Yong, Zhao,Haixia et Li,Yaowei, « Research on secure transmission of SOAP messages », Computer Supported Cooperative Work in Design, 2008. CSCWD 2008. 12th International Conference on,‎ , p. 771 - 776 (ISBN 978-1-4244-1651-6, DOI 10.1109/CSCWD.2008.4537076)
  • (en) Shehab,Mohamed, Bhattacharya,Kamal et Ghafoor,Arif, « Web Services Discovery in Secure Collaboration Environments », ACM Transactions on Internet Technology (TOIT), vol. 8, no 1,‎ (ISSN 1533-5399, DOI 10.1145/1294148.1294153)
  • Guillaume, HARRY, « Failles de sécurité des applications Web », (TOIT), vol. 1.3,‎ , p. 18
  • (en) Yutaka, Oiwa, Hajime, Watanabe et Hiromitsu, Takagi, « PAKE-based mutual HTTP authentication for preventing phishing attacks », ACM,‎ , p. 1143-1144 (ISBN 978-1-60558-487-4)
  • (en) Catalin, Boja, « Journal of Mobile, Embedded and Distributed Systems », (Security Survey of Internet Browsers Data Managers), vol. III, no 3,‎ (ISSN 2067-4074)
  • (en) Aurélien, DUMAINE, « Évolution d’internet : confiance, identités, vie privée, statut des données et modèles économiques », (A),‎ , p. 18
  • (en) Johns, Martin, Lekies, Sebastian, Braun, Bastian et Fiesch, Benjamin, « BetterAuth: Web Authentication Revisited », Proceedings of the 28th Annual Computer Security Applications Conference,‎ , p. 169-178 (ISBN 978-1-4503-1312-4, DOI 10.1145/2420950.2420977)
  • (en) Darwish, A. et Bataineh, E., « Eye tracking analysis of browser security indicators », International Conference on Computer Systems and Industrial Informatics (ICCSII),‎ , p. 1 - 6 (ISBN 978-1-4673-5155-3, DOI 10.1109/ICCSII.2012.6454330)
  • (en) « ISO/IEC 9126 International Standard - Information Technology – Software product evaluation », Quality characteristics and guidelines for their use,‎ (lire en ligne)
  • (en) Gasti, Paolo et B. Rasmussen, Kasper, « On The Security of Password Manager Database Formats », Lecture Notes in Computer Science, vol. 7459,‎ , p. 770 -787 (lire en ligne)
  • (en) Silver, David, Jana, Suman, Chen, Eric, Jackson, Collin et Boneh, Dan, « Password Managers: Attacks and Defenses », Proceeding SEC'14 Proceedings of the 23rd USENIX conference on Security Symposium,‎ , p. 449-464 (ISBN 978-1-931971-15-7)
  • (en) « Protect your synced data », Google,‎ (lire en ligne)
  • « Recommandations de sécurité relatives aux mots de passe », Agence nationale de la sécurité des systèmes d’information,‎ , p. 7 (lire en ligne)
  • (en) Chen,Guanchen, Johnson, Matthew F., Marupally, Pavan R., Singireddy, Naveen K. et Yin, Xin, « Combating Typo-Squatting for Safer Browsing », Proceedings of the 2009 International Conference on Advanced Information Networking and Applications Workshops,‎ , p. 31-36 (ISBN 978-0-7695-3639-2, DOI 10.1109/WAINA.2009.98)
  • (en) Stamm, Sid, Ramzan, Zulfikar et Jakobsson, Markus, « Drive-by Pharming », Proceedings of the 9th International Conference on Information and Communications Security,‎ , p. 495–506 (ISBN 978-3-540-77047-3)
  • (en) P. Burkholder, « “SSL Man-in-the-Middle Attacks”, SANS Institue InfoSec Reading », ., vol. .,‎
  • (en) Bin Mat Nor, F., Jalil, K.A. et Manan,J.-L.A., « An enhanced remote authentication scheme to mitigate man-in-the-browser attacks », 2012 International Conference on Cyber Security, Cyber Warfare and Digital Forensic (CyberSec),‎ , p. 271-276 (ISBN 978-1-4673-1425-1, DOI 10.1109/CyberSec.2012.6246086)
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:Smail_el/Brouillon&oldid=156407203 ».